i think that we have to initialise with empty array here

what is the motivation of this change? isn't it now different than the way how DOM API works?

if an element has no id property/attribute what returns accessing the $0.id? it does not return undefined but empty string since it is defined as DOMString in the IDL. I would expect the same. Even setting undefined back $0.id = undefined should convert the undefined to 'undefined' it should not allow setting undefined back.

Same is true for enums for example for the input, setting type to e.g. $0.type="petar" returns back as text when $0.type is accessed again although the type attribute will be written as type="petar". So there is a validation for enums and silently fails to default value.

Also true for numeric values. for example for input type number, setting an invalid value $0.valueAsNumber = 'petar' will log an error and return NaN when $0.valueAsNumber is read back again.

a lot of topics to cover here, posting as separate comments

1. undefined is a valid value for a lot of properties (there are properties that accept undefined and are initialized with undefined even before the change). accessibleName specifically is used in the AriaLabelHelper.ts and has a truthy check that treats it as undefined even when empty string is passed.

		if (accessibleEl.accessibleName) {
			return accessibleEl.accessibleName;
		}

		return undefined;

There are a lot of acc places where an empty string is different from undefined and a lot of checks for "" that return undefined (empty string is unwanted from acc perspective, but used to come from the framework).

If you still want accessible name to be initialized to "", feel free to change it. This will also remove the ? and all typescript users will be unable to assign undefined. It's up to you, but my guidance is, if undefined and "" are treated the same way, then simply go with undefined as default.

2. reading properties and expecting some fallback to be applied - reading properties is used in jquery style programming, real programming models like react/angular/vue will have some kind of model and will only write to the properties, or read values from events.

In this case, we didn't want to mimic existing browser behaviour if it means adding more code, especially code that introduces "magic". The typescript type already specifies valid values and components expect to work with valid values anyway.

3. enums and fallback - assigning an invalid value is clearly a developer error and should be fixed. If the developer assigned button.design = "Netigave" (notice the typo), it would be better to find out and correct it instead of falling back to "Default"

Enums values when used in CSS via attribute selectors already have a fallback - there should be a css rule without the attribute that will catch invalid values as well.

EDIT: enums value are also hardcoded in templates by the developers, they are not bound to some model, nor are they determined from user input. If this is the case, the application should take care to privide a default, not the framework.

4. same for numbers - if someone passes a string to a number field, they clearly made an error that should be fixed instead of falling back to some value and masking the error. The component API clearly states that a number is expected, why should it work any other way?

5. in the future, ES standard decorators will provide means to differentiate what the initializer value was. Then we could use it as a fallback as well. As it is now with experimental decorators, there is no way to find out what the initializer value was - it is indistinguishable from normal setters. So what you describe could be introduced in the future.

Another option is to create a decorator (fallback, or guard) that instruments the setter and takes an addtional value, but this will be repeating the values like this which is undesired:

@property()
@fallback("text")
type = "text"

This repetition does not look good, and normal cases should be covered when using typescript with a programming model - it simply isn't necessary to have fallbacks.

let's have a call if you want a deeper discussion or use one of the regular meetings.